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;_( ' Abstract. Formal specification is widely employed in the construction 

, ^ I of high-quality software. However, there is often a huge gap between for- 

mal specification and actual implementation. While there is already a vast 
body of work on software testing and verification, the task to ensure that 
r^ ^ an implementation indeed meets its specification is still undeniably of 

great difficulty. ATS is a programming language equipped with a highly 
expressive type system that allows the programmer to specify and imple- 
, 1 , ment and then verify within the language itself that an implementation 

^ , ' meets its specification. In this paper, we present largely through examples 

a programmer-centric style of program verification that puts emphasis on 
requesting the programmer to explain in a literate fashion why his or her 
code works. This is a solid step in the pursuit of software construction 
that is verifiably correct according to specification. 



> 

O ' 1 Introduction 



In order to be precise in building software systems, we need to specify what such 
a system is expected to accomplish. In the current day and age, software speci- 



m 

*vj . fication, which we use in a rather loose sense, is often done in forms of varying 

degree of formalism, ranging from verbal discussions to pencil/paper drawings 
to various diagrams in modeling languages such as UML [RIICF05] to formal 
specifications in specification languages such as Z [Spi92], etc. Often the main 

j^ I purpose of software specification is to establish a mutual understanding among a 

Jh ' team of developers. After the specification for a software system is done, either 

- - - formally or informally, we need to implement the specification in a programming 

language. In general, it is exceedingly difficult to be reasonably certain whether 
an implementation actually meets its specification. Even if the implementation 
coheres well with its specification initially, it nearly inevitably diverges from the 
specification as the software system evolves. The dreadful consequences of such 
a divergence are all too familiar; the specification becomes less and less reliable 
for understanding the behavior of the software system while the implementation 
gradually turns into its own specification; for the developers, it becomes increas- 
ingly difficult and risky to maintain and extend the software system; for the users, 
it requires extra amount of time and effort to learn and use the software system. 
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The design of ATS [Xi04,Xi08] was largely inspired by Martin-Lof s construc- 
tive type theory [Mar85], which was originally developed for the purpose of es- 
tablishing a foundation for mathematics. Within ATS, there are a static com- 
ponent (statics) and a dynamic component (dynamics). Intuitively, the statics 
and dynamics are each for handling types and programs, respectively. In par- 
ticular, specification is done in the statics and implementation in the dynamics. 
Given a specification, how can we effectively ensure that an implementation of 
the specification indeed implements according to the specification? We expect 
that the programmer who does the implementation also constructs a proof in the 
theorem-proving subsystem of ATS to demonstrate it. This is a style of program 
verification that puts its emphasis on requesting the programmer to explain in a 
literate fashion why his or her code works, and thus we refer to it as a programmer- 
centric approach to program verification. The primary contribution of the paper 
lies in our effort identifying such a style of program verification as well as putting 
it into practice. 

In theorem-proving systems such as Coq [The03] and NuPrl [C+86], a spec- 
ification is encoded as a type; if a proof inhabiting the type is made available, 
then a program guaranteed to meet the specification can be automatically ex- 
tracted out of the proof. Alternatively, formal annotations can be developed for 
a program logic such as Hoare logic [Hoa69] or separation logic [Rey02]; a pro- 
gram interspersed with annotations for a chosen property can be passed to a 
tool that generates proof obligations according to the underlying program logic, 
and the generated proof obligations can often be discharged through automated 
theorem-proving. For instance, KML [TGK09] is a system of this kind for pro- 
gram verification. The approach to program verification in ATS somewhat lies in 
between the two aforementioned ones: It cohesively combines programming with 
theorem-proving . 

We organize the rest of the paper as follows. In Section 2, we give a brief 
overview of ATS. We then present in Section 3 a typical style of program verifi- 
cation in ATS that combines programming with theorem-proving. In Section 4, 
we employ some examples to illustrate that ATS is well-equipped with features to 
support program verification that is both fiexible and effective for practical use. 
Last, we mention some related work in Section 5 and then conclude. 
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Fig. 1. Some formal syntax for statics and dynamics of ATS 



2 Overview of ATS 

We give some formal syntax of ATS in Figure 1. The language ATS has a static 
component (statics) and a dynamic component (dynamics). The statics includes 
types, props and type indexes while the dynamics includes programs and proofs. 
The statics itself is a simply typed language and a type in it is referred as a sort. 
For instance, we have the following base sorts in ATS: addr, bool, int, prop, type, 
etc; we use L, B and / for static addresses, booleans and integers of the sorts 
addr, bool and int, respectively; we use T for static terms of the sort type, which 
are types assigned to programs; we use P for static terms of the sort prop, which 
are props assigned to proofs. 

Types and props may depend on one or more type indexes of static sorts. A 
special case of such indexed types is singleton types, which are each a type for 
only one specific value. For instance, bool(i3) is a singleton type for the boolean 
value equal to B, and int(/) is a singleton type for the integer equal to /, and 
ptr(L) is a singleton type for the pointer that points to the address (or location) 
L. Also, we can quantify over type index variables universally and existentially to 
form quantified types and props. 

We use proving-types of the form (P | T) for combining proofs with programs, 
where P and T stand for a prop and a type, respectively. One may think of the 
proving-type (P | T) as a refinement of the type T because P often constrains 
some of the indexes appearing in T. For example, the following type: 

(ADD(?7i,n,p) I int (to), int (n), int (p)) 

is a proving-type of the sort type for a tuple of integers {m,n,p) along with a 
proof of the prop ADD (to, n, p) which encodes m-\-n = p. Given a static boolean 
term B and a type T, we can form two special forms of types: guarded types of 
the form B D T and asserting types of the form BAT. Following is an example 
involving singleton, guarded and asserting types: 

Va : int. a > D (int(a) -^ 3a' : int. {a' < A int(a'))) 

The meaning of this type should be clear: Each value that can be assigned this 
type represents a function from nonncgative integers to negative integers. 

3 Overview of Program Verification in ATS 

We now use a simple example to illustrate the idea of programming with theo- 
rem proving. Suppose we want to compute Fibonacci numbers, which are defined 
inductively as follows: 

fib{0)^0 fib{l) = l fib{n + 2)=fib{n)+fib{n+l)iorn>=0 

A direct implementation of the function fib in ATS can be done as follows: 

fun fib (n:int): int = 

if n = then else (if n = 1 then 1 else fib (n-1) + fib (n-2)) 
// end of [fib] 



where the syntax is ML-hkc. This is a terribly impractical implementation of 
exponential time-complexity. In C, we can give an implementation as follows that 
is of 0(n) time-complexity: 

int fibc (int n) { 

int tmp, fO = 0, fl = 1 ; 

while (n— > 0) { tmp = fl ; fl = fO + fl ; fO = tmp ; > ; 

return fO ; 
> // end of [fibc] 

There is obviously a logic gap between the definition of fib and its implementation 
fibc in C.^ In ATS, we can give an implementation oi fib that completely bridges 
this gap. First, we need a way to encode the definition of fib into ATS, which is 
fulfilled by the declaration of the following dataprop: 

dataprop FIB (int, int) = 

I FIBO (0, 0) I FIBl (1, 1) 

I {n:nat} {rO,rl:int} 
FIB2 (n+2, rO+rl) of (FIB (n, rO) , FIB (n+1, rl)) 
// end of [FIB] 

where the concrete syntax {. . .} is for universal quantification in ATS. This 
declaration introduces a type (or more precisely, a type constructor) FIB for 
proofs. Such a type is referred to as a prop (or prop-type) in ATS. Intuitively, if 
a proof can be assigned the type FIB(n, r) for some integers n and r, then fib{n) 
equals r. In other words, FIB(ri, r) encodes the relation fib{n) = r. There are 
three constructors FIBO, FIBl and FIB2 associated with FIB, which are given 
the following types corresponding to the three equations in the definition oi fib: 



FIBO 
FIBl 
FIB2 



()^FIB(0,0) 
^FIB(1,1) 
Vn : nat.\/rQ : int.Vri : int. 

(FIB(n, ro), FIB(n, ri) -^ FIB(n + 2, ro + ri) 



For instance, FIB2{FIB0{),FIB1 ()) is a term of the type FIB(2, 1), attesting to 
fib(2) = 1. In Figure 2, the implemented function fibats is assigned the following 
type: 

fibats : Vn : nat. int(n) -^ 3r : mt.(FIB(n,r) | int(r)) 

where | is just a separator (like a comma) for separating a proof from a value. 
For each integer /, int(/) is a singleton type for the only integer whose value is 
I. When fibats is applied to an integer of value n, it returns a pair consisting of a 
proof and an integer value r such that the proof, which is of the type FIB(n, r), 
asserts fib{n) = r. Therefore, fibats is a verified implementation oi fib. Note that 
the loop function in Figure 2 directly corresponds to the while-loop in the body 
of fibc. Also, we emphasize that proofs are completely erased after typechecking. 
In particular, there is no proof construction at run-time. 



We do not address the issue of possible arithmetic overflow here. 



// 

// the syntax [...] is for existential quantification 

// 

fun fibats -[ninat}- (n: int n) 

: [r:int] (FIB (n, r) I int r) = let 

fun loop 

{n,i:nat I i <= n} {rO,rl:int} ( 
pfO: FIB (i, rO), pfl: FIB (i+1, rl) 

I rO: int (rO) , rl: int (rl) , ni : int(n-i) 

) : [r:int] (FIB (n, r) I int (r)) = 

if ni > then 

loop {n,i+l} (pfl, FIB2 (pfO, pfl) I rl, rO+rl, ni-1) 

else (pfO I rO) 
in 

loop (FIBOO, FIBlO I 0, 1, n) 
end // end of [fibats] 



Fig. 2. A verified implementation of fib in ATS 

4 Programmer-Centric Verification 

By programmer-centric verification, we mean a verification approacli that puts 
the programmer at the center of the verification process. The programmer is 
expected to explain in a hterate fashion why his or her implementation meets a 
given specification. The programmer may rely on external knovirledge when doing 
verification, but such knowledge should be expressed in a format that is accessible 
to other programmers. We will employ some examples in this section to elaborate 
on programmer-centric verification. 

4.1 Example: Insertion Sort on Generic Lists 

In Figure 3, we give a standard implementation of insertion sort written in ATS 
that takes a generic list and a comparison function and returns a generic list that 
is sorted according to the comparison function. Note that the use of generic lists 
clearly indicates our strive for practicality. In the literature, a similar presentation 
would often use integer lists (instead of generic lists) , revealing the difficulty in 
handling polymorphism and thus weakening the argument for practical use of 
verification. We have no such difficulty. The implementation we present guarantees 
based on the types that the output list is of the same length as the input list. We 
also give a verified implementation of insertion sort in Figure 4 that guarantees 
based on the types that the output list is a sorted permutation of the input list. 
The fact that this verified implementation can be done in such a concise manner 
should yield strong support for the underlying verification approach. 

Suppose that a programmer did the implementation in Figure 3. Obviously, 
the programmer did not do the implementation in a random fashion; he or she 
did it based on some kind of (informal) logic reasoning. We will see that ATS 
provides programming features such as abstract props and external lemmas for 



// 

// list (a, n) is the type for a list of length n 

// in which each element is of the type T. 

// 

fun-[a:type} insert ■Cn:nat} 

(xs: list (a, n) , Ite: (a, a) -> bool) : list (a, n) = let 
fun ins {n:nat}- 

(x: a, xs : list (a, n) , Ite: (a, a) -> bool): list (a, n+1) = 
case xs of 

I list_cons (xl, xsl) => 
if Ite (x, xl) then 

list_cons (x, xs) else list_cons (xl, ins (x, xsl, Ite)) 
// end of [if] 
I list_nil () => list_cons (x, list_nil ()) 
// end of [ins] 
in 

case xs of 

I list_cons (x, xsl) => ins (x, insort (xsl, Ite), Ite) 
I list_nil => list_nil () 
end // end of [insort] 



Fig. 3. A standard implementation of insertion sort 

turning such informal reasoning into formal verification. In particular, we can turn 
the implementation of insertion sort in Figure 3 into the verified one in Figure 4 
by following a verification process. 

In Figure 5, we first introduce an abstract type constructor E. Given a type 
T and an integer /, E(T, /) is a singleton type for a value of the type T with an 
(imaginary) integer name /. In ATS, the user-defined sorts (datasorts) can be in- 
troduced in a manner similar to the introduction of user-defined types (datatypes) 
in a ML-like language. We introduce a datasort Hist for representing sequences of 
(static) integers. We may simply write nil and cons for ilist_nil and ilist-cons, re- 
spectively, if there is no potential confusion. Note that there is no mechanism 
for defining recursive functions in the statics, and this is a profound restric- 
tion that give rise to a unique style of verification in ATS. We lastly define a 
datatype glist: Given a list of values of types E(r, /i), . . . , E(r, J„), the type 
glist(T, cons{Ii, . . . , cons{In,nil))) can be assigned to this particular list. We may 
also simply write nil and cons for glist_nil and glist-cons, respectively, if there is 
no potential confusion. Please note that glist is in the dynamics while Hist is in 
the statics. 

To verify insertion sort, we first introduce an abstract prop as follows such 
that SORT(a;s, 2/s) means that ys is a sorted permutation of xs: 

absprop SORT (xs:ilist, ys:ilist) 

Let Ite(a) be a shorthand for the following type: 

Va : type\fxi : intyx2 '■ mi.(E(a, ij ), E(a, xg)) — > bool(a;j < ig) 



fmi{a:type} insert 

{xsiilist} (xs: glist (a, xs) , Ite: Ite(a)) 
: [ys:ilist] (SORT (xs, ys) I glist (a, ys)) = let 
fun ins -[xiint}- -[ysl : ilist]- ( 
pford: ORD (ysl) I 

x: E (a, x) , ysl: glist (a, ysl), Ite: Ite(a) 
) : [ys2:ilist] (SORT (cons (x, ysl), ys2) I glist (a, ys2)) 
case ysl of 

I glist_cons (yl, yslO) => 
if Ite (x, yl) then let 

prval pford = ORD_ins {x} (pford) 
prval pfperm = PERM_refl () 
prval pfsrt = 0RDPERM2S0RT (pford, pfperm) 
in 

(pfsrt I cons (x, ysl)) 
end else let 

prval pfordl = ORD_tail (pford) 

val (pfsrtl I ys20) = ins (pfordl I x, yslO, Ite) 
prval pfsrt2 = SORT_ins {x} (pford, pfsrtl) 
in 

(pfsrt2 I cons (yl, ys20)) 
end // end of [if] 
I glist_nil => (SORT_sing () I cons (x, nil ())) 
// end of [ins] 
in 

case xs of 

I glist_cons (x, xsl) => let 

val (pfsrtl I ysl) = insert (xsl, Ite) 
prval pfordl = S0RT20RD (pfsrtl) 
prval pfperml = SDRT2PERM (pfsrtl) 
prval pfperml_cons = PERM_cons (pfperml) 
val (pfsrt2 I ys2) = ins (pfordl I x, ysl, Ite) 
prval pford2 = S0RT20RD (pfsrt2) 
prval pfperm2 = SDRT2PERM (pfsrt2) 
prval pfpermS = PERM_traji (pfperml_cons, pfperm2) 
prval pfsrtS = DRDPERM2S0RT (pford2, pfpermS) 
in 

(pfsrtS I ys2) 
end // end of [intlist_cons] 
I glist_nil => (SORT_nil () I nil ()) 
end // end of [insort] 



Fig. 4. A verified implementation of insertion sort 



abstype E (a:type, x:int) // abstract type constructor 
datasort ilist = ilist_nil of () I ilist_cons of (int, ilist) 
datatype glist (a:type, ilist) = 

I {x:int} {xs: ilist}- 
glist_cons (a, cons (x, xs)) of (E (a, x) , glist (a, xs)) 

I glist_nil (a, nil) of () 



Fig. 5. A generic list type indexed by the names of list elements 



If we can assign the following type to insort: 

Va : typeixs : ilist. 

(glist(a,a;s), Ite(a)) — > 3ys : ilist. {SOI{T{xs,ys) \ glist(a, ys)) 

then insort is verified as the type simply states that the output list is a sorted 
permutation of the input list. 

For the purpose of verification, we also introduce the following two abstract 
props: 

absprop ORD (xs: ilist) 

absprop PERM (xs: ilist, ys: ilist) 

Given xs and ys, ORD(a;s) means that xs is ordered according to the ordering 
< on integers and PERM(xs, ys) means that ys is a permutation of xs. 



S0RT20RD 

S0RT2PERM 

0RDPERM2S0RT 

SORT.ml 

SORT.smg 

ORD Jail 

ORDJns 

PERM.refl 
PERMjran 

PERM. cons 

SORT.ms 



Mxs : ilisfiys : ilist. SOIlT{xs, ys) -> ORD(jys) 
\/xs : ilistiys : ilist. SOTiT{xs,ys) -> PERM(j:s,j/s) 
Vxs : ilisfiys : ilist. 

(ORD(jys),PERM(a:s,ys)) -^ SORT(a;s, jys) 
-^ SORT {nil, nil) 

\/x : int. — > SORT(cons(a;, nil), cons{x, nil)) 
\/y : infiys : ilist. ORD(cons(j/, j/s)) — ^ ORD(j/s) 
Va; : int\fy : infiys : ilist. x < y D 

ORD(cons(2y, j/s)) — > OIi.'D{cons{x,cons{y,ys))) 
Vxs : ihst. ~> PERM(a;s,a;s) 
Vxs : ilist\/ys : ilist\/zs : ilist. 

(PERM(2;s,i/s),PERM(2/s,zs)) -> PERM(a:s, zs) 
\fx : infixsi : ilistixsz : ilist. 

PERM(a;si, XS2) — >■ PERM(cons(a;, xs^), cons(x, XS2)) 
Vx : int\/y : int\/ysi : ilist\/ys2 : ilist. x > y D 

(ORD(cons(y, ysi)), SORT(cons(a;, ysi), ys2)) — 5- 

SORT(cons(a;, cons(y, ys\)), cons(y, ys2)) 



Fig. 6. Some external lemmas needed for verifying insertion sort 



S0RT20RD: If ys is a sorted version of xs, then ys is ordered 

S0RT2PERM: If ys is a sorted version of xs, then j/s is a permutation of a::s 

0RDPERM2S0RT: if j/s is ordered and is also a permutation of xs, then ys is a 

sorted version of xs. 

SORTjnil: The empty list is a sorted version of itself. 

SORT^sing: A singleton list is a sorted version of itself. 

ORDJ,ail: If a non-empty list is ordered, then its tail is also ordered. 

ORDjins: \i x < y holds and cons{y,ys) is ordered, then cons {x, cons {y,ys)) is also 

ordered. 

PERMjrefl: Each list is a permutation of itself 

PERM_tran: The permutation relation is transitive. 

PERM_cons: If XS2 is a permutation of xsi, then cons{x,xs2) is a permutation of 

cons{x,xsi). 

SORTjins: If x > y holds, cons{y,ysi) is ordered and ys2 is a sorted version of 

cons{x,ysi), then cons{y,ys2) is a sorted version of cons {x, cons {y,ysi)). 



Fig. 7. Some explanation for the lemmas in Figure 6 



When verifying insort, we essentially try to justify each step in the code pre- 
sented in Figure 3. This justification process may introduce various external lem- 
mas. For instance, the code presented in Figure 4 makes use of the lemmas listed 
in Figure 6. 

In order to prove these lemmas, we need to define SORT, ORD and PERM 

explicitly, and we can indeed do this in the theorem-proving subsystem of ATS. 
However, this style of verifying everything from basic definitions can be too great a 
burden in practice. Suppose that we try to construct a mathematical proof and we 
need to make use of the proposition in the proof that the standard permutation 
relation is transitive. It is unlikely that we provide an explicit proof for this 
proposition as it sounds so evident to us. To put it from a different angle, if 
constructing mathematical proofs required that every single detail be presented 
explicitly, then studying mathematics would unlikely to be feasible. Therefore, we 
strongly advocate a style of theorem-proving in ATS that models the way we do 
mathematics. 

The implementation of insertion sort on generic lists in Figure 3, which can 
be obtained from erasing proofs in Figure 4, is guaranteed to be correct if all of 
the lemmas in Figure 6 are true. Some explanation of these lemmas is given in 
Figure 7. It is probably fair to say that these lemmas are all evidently true except 
the last one: SORT_ins. If we are unsure whether the lemma SORT_ins is true or 
not, we can construct a proof in ATS or elsewhere to validate it. For instance, we 
can even give an informal proof as follows: Note that PERM(cons(a;,2/si),2/S2) 
holds as ys2 is a sorted version of cons{x,ysi). Hence, cons{y,ys2) is a permu- 
tation oi cons{x,cons(y,ysi)). Since cons{y,ysi) is ordered, y is a lower bound 
for the elements in ysi. Hence, y is a lower bound for elements in ys2 as x > y 
holds, and thus, cons{y, ys2) is ordered. Therefore, cons{y, ys2) is a sorted version 
of cons{x, cons(y, ysi)). 



What is of crucial importance is that SORT_ins is a lemma that is manually 
introduced and can be readily understood by any programmer with adequate 
training. This is a direct consequence of programmer-centric verification in which 
the programmer explains in a literate fashion why his or her implementation meets 
a given specification. 



fun-[a:type]- 
qsrt -Cnrnat} 

(xs: list (a, n) , Ite: Ite a) : list (a, n) = 

case+ xs of 

I list_cons (x, xs) => part (x, xs, Ite, list_iiil () , list_iiil ()) 

I list_nil () => list_nil () 

aind part {p:nat} {q,r:nat} ( 

xO: a, xs: list (a, p) , Ite: Ite(a), ys : list (a, q) , zs : list (a, r) 
) : list (a, p+q+r+1) = 
case+ xs of 
I list_cons (x, xs) => 
if Ite (x, xO) then 

part (xO, xs, Ite, list_cons (x, ys) , zs) 
else 

part (xO, xs, Ite, ys, list_cons (x, zs)) 
// end of [if] 
I list_nil => let 

val ys = qsrt (ys, Ite) and zs = qsrt (zs, Ite) 
in 

append (ys, list_cons (xO, zs)) 
end // end of [list_nil] 



Fig. 8. A standard implementation of quicksort 



4.2 Example: Quicksort on Generic Lists 

We give a standard implementation of quicksort on generic lists in Figure 8. The 
reason that we use lists instead of arrays is solely for simplifying the presentation. 
As far as verification is concerned, there is really not much difference between 
lists and arrays. Note that we have already made various verification examples 
available on-line that involve arrays. 

The implementation in Figure 8 guarantees based on the types that the output 
list is of the same length as the input list. We also give a verified implementation 
of quicksort in Figure 9 that guarantees based on the types that the output list is 
a sorted permutation of the input list. The verified implementation is essentially 
obtained from the process to explain why the function qsrt in Figure 8 always 
returns a list that is the sorted version of the input list. 



fun{a:type} 

qsrt {xs:ilist} ( 

xs : glist (a, xs) , Ite: Ite a 
) : [ys:ilist] (SORT (xs, ys) I glist (a, ys)) = 
case+ xs of 
I glist_cons (x, xs) => let 

val (pford, pfuni I res) = 

part (UB_nil () , LB.nil () I x, xs, Ite, nil (), nil ()) 
prval pfperm = UNI0N4_perm (pfuni) 
in 

(0RDPERM2S0RT (pford, pfperm) I res) 
end 
I glist_nil => (SORT_nil () I nil ()) 

and part 

■[xO:int} ■[xs:ilist} {ys,zs : ilist} ( 
pfl: UB (xO, ys) , pf2: LB (xO, zs) 
I xO: E (a, xO) , xs : glist (a, xs) , Ite: Ite(a) 
, ys : glist (a, ys) , zs : glist (a, zs) 
) : [res: ilist] ( 

ORD (res), UNI0N4 (xO, xs, ys, zs, res) I glist (a, res) 
) = 

case+ xs of 

I glist_cons (x, xs) => 

if Ite (x, xO) then let 
prval pfl = UB_cons (pfl) 
val (pford, pfuni I res) = 

part (pfl, pf2 I xO, xs, Ite, cons (x, ys) , zs) 
prval pfuni = UNI0N4_movl (pfiuii) 
in 

(pford, pfuni I res) 
end else let 

prval pf2 = LB_cons (pf2) 
val (pford, pfuni I res) = 

part (pfl, pf2 I xO, xs, Ite, ys , cons (x, zs)) 
prval pfuni = UNI0N4_mov2 (pfuni) 
in 

(pford, pfuni I res) 
end // end of [if] 
1 glist_nil => let 

val (pfsrtl I ys) = qsrt (ys, Ite) 
val (pfsrt2 I zs) = qsrt (zs, Ite) 
val (pfapp I res) = append (ys, cons (xO, zs)) 
prval pfordl = S0RT20RD (pfsrtl) 
prval pford2 = S0RT20RD (pfsrt2) 
prval pfperml = SDRT2PERM (pfsrtl) 
prval pfperm2 = SDRT2PERM (pfsrt2) 
prval pfl = UB_perm (pfperml, pfl) 
prval pf2 = LB_perm (pfperm2, pf2) 

prval pford = APPEND_ord (pfl, pf2, pfordl, pford2, pfapp) 
prval pfuni = APPEND_union4 (pfperml, pfperm2, pfapp) 
in 

(pford, pfuni I res) 
end // end of [glist_nil] 
// end of [part] 



Fig. 9. A verified implementation of quicksort 



LBjnil 

UB.nil 

LB_cons 

UB.cons 

LBjperm 

UBjperm 

UNI0N4.perm 

UNION4.movl 

UNION i_mov2 

APPEND. ord 

APPEND.umon4 



\/x : int. -^ LB(a;, nil) 

\/x : int. — > UB(k, nil) 

\/xo : intVx : intVxs : Hist. Xg < x Z) 

LB(a;o, xs) -^ LB(a;o, cons(x, xs)) 

Vxo : infix : infixs : Hist, xo > x Z) 

UB(a;o, xs) — )• UB(a;o, cons{x, xs)) 

\/x : infixsi : ilist\/xs2 : Hist. 

(PERM(a;si,a;s2),LB(a;,a;si)) — > LB(a;,a;s2) 

\/x : infixsi : ilist^/xs^ : Hist. 

(PERM(a;si,a;s2),UB(a;,a;si)) -^ \J'B[x,xs2) 

Vx : infixs : ilistWres : Hist. 

UNION4{x, xs, nil, nil, res) — >■ PERM.{cons{x,xs),re. 
Vxo : infix : infixs : ilistiys : ilisfizs : tltstires : Hist. 

UNION4(a;0, xs, cons{x, ys),zs, res) -^ 

UNION4(2;0, cons{x, xs), ys, zs, res) 
ixo : infix : intixs : ilistiys : ilisfizs : lUstires : Hist. 

UNION4(a;0, xs, ys, cons{x, zs),res) -^ 

UNION4(a;0, cons{x, xs), ys, zs, res) 
ix : intiys : ilistizs : Histires : Hist. 

(UB(a;, ys), LB(a;, zs), OKD{ys),0'RD{zs), 
APPEN'D{ys,cons{x, zs),res)) -^ ORD(res) 
Va; : intiys : ilistiysi : ilisfizs : ilistizsi : Histires : Hist. 

(PERM(j/s, ysi), PERM(zs, zsi), 
APPEN'D{ysi,cons{x,zsi),re.s)) — > 

UNION4(a;, nil, ys, zs, res) 



Fig. 10. Some external lemmas needed for verifying quicksort 



LBjperm: If a; is a lower bound for xsi and xs\ is a permutation of xs2, then x is 

also a lower bound for XS2. 

UBjperm: If x is an upper bound for xsi and xsi is a permeation of xs2, then x is 

also a upper bound for XS2. 

UNI0N4-perm: If \res\ = {x} U |a;sj, then res is a permutation of cons{x,xs). 

UNION4-movl: If \res\ = {xq} U |xs| U \cons{x,ys)\ U \zs\, then \res\ = {xo} U 

\cons{x, xs)\ U \ys\ U \zs\. 

UNION4_mov2: If |res| = {xq} U 1xs| U \ys\ U \cons{x,zs)\, then \res\ = {xo} U 

\cons{x, xs)\ U \ys\ U \zs\. 

APPEND^ord: If x is an upper bound for ys and a lower bound for zs, both ys 

and zs are ordered and res is the concatenation of ys and cons{x,zs), then res is 

ordered. 

APPENDjunion4: If ys\ is a permutation of ys, zsi is a permutation of zs and res 

is the concatenation of ys\ and cons{x, zs\), then \res\ = {x} U \ys\ U \zs\. 



Fig. 11. Some explanation for the lemmas in Figure 10 



Wc now explain that the verified implementation of quicksort can be trusted. 
The function append in the implementation is given the following type: 

Va : type.\fxsi : ili.st\fxs2 '■ Hist. 
(glist(a,xsi),glist(a,xs2)) -^ 
3res : ilist.{Al?PEN'D{xsi,xs2,res) \ glist(a, res)) 

where APPEND is an abstract prop. Given lists xsi,xs2 and res, the intended 
meaning of APPEND(xsi,xs2,''es) is obvious: it states that the concatena- 
tion of xsi and xs2 is res. Both LB and UB are introduced as abstract props: 
LB(x, xs)/UB(a;, xs) means that x is a lower/upper bound for the elements in 
xs. Another introduced abstract prop is UNION4: Given x, xs, ys, zs and res, 
UNION4(x, xs, j/s, zs, res) means that the following equation holds 

\res\ — {x} U \xs\ U \ys\ U \zs\ 

where | • | turns an integer list into a multiset. The external lemmas in Figure 9 
are listed in Figure 10 and some explanation are given in Figure 11 for some of 
these lemmas. 



4.3 Many Other Examples 

There are also a variety of examples available on-line^ which can further illus- 
trate a style of programmer-centric verification in ATS that combines program- 
ming with theorem-proving cohesively. In particular, there are examples involving 
arrays, heaps, balanced trees, etc. 



5 Related Work and Conclusion 

Given the vastness of the field of program verification, we can only mention some 
closely related work in this section. 

In the Coq theorem-proving system [DFH+93], programs can be extracted 
from proofs [PM89] . In [FM99] , the authors specified the orderedness property as 
well as the permutation relation on the array structure and gave verification for 
three sorting algorithms. However, Coq is primarily designed for theorem-proving 
instead of programming, and its use as a programming language is a bit unwieldy 
and limited. 

Ynot [CMM+09] is an axiomatic extension of the Coq proof assistant for spec- 
ifying and verifying properties of imperative programs. The programmer can en- 
code a new domain by providing key lemmas in an ML-like embedded language. 
Relying on Coq to do theorem-proving, Ynot mixes the automated proof genera- 
tion with manual proof construction, attempting to relieve the programmer from 
the heavy burden that would otherwise be necessary. 

In the specification language KML [TGK09], the programmer can add anno- 
tations such as preconditions, postconditions and invariants into Java programs. 



Please see http://www.ats-lang.org/EXAMPLE/PCPV 



and a tool is provided for generating proof obligations automatically from the 
annotated source file, which are to be discharged by various automatic provers. 
Permutation can be specified based on the natural concept of multiset. Often, ex- 
ternal assertions need to be provided along together with the code so as to make 
the program verifiable by existing theorem provers. 

The work on extended static checking (ESC) [Det96] also puts emphasis on 
employing formal annotations to capture program invariants. These invariants 
may be verified through (light-weighted) theorem proving. ESC/Java [FRL+02] 
generates verification-conditions based on annotated Java code and uses an auto- 
matic theorem-prover to reason about the semantics of the programs. It can catch 
many basic errors such as null dereferences, array bounds errors, type cast errors, 
etc. With more emphasis on usefulness, soundness is sacrificed in certain cases to 
reduce annotation cost or to improve checking speed. 

VeriFast [JSPIO] is another system for verifying program properties through 
source code annotation. It supports direct insertion of simple proof steps into the 
source code while allowing rich and complex properties to be specified through 
inductive datatypes and fixed-point functions. VeriFast provides a program verifier 
for C and Java that supports interactive insertion of annotations into source code. 

The paradigm of programming with theorem-proving as is supported in the 
ATS programming language system is a novel invention. In particular, this pro- 
gramming paradigm is fundamentally different from program extraction (from 
proofs) as is supported in theorem-proving systems such as Coq. In this paper, 
we have argued for a style of program verification that puts emphasis on request- 
ing the programmer to formally explain in a literate fashion why the code he or 
she implements actually meets its specification. Though external lemmas intro- 
duced during a verification process can be discharged by formally proving them 
in ATS, doing so is often expensive in terms of effort and time. One possibility is 
to characterize such lemmas into different categories and then employ (external) 
theorem-provers specialized for a particular category to prove lemmas in that 
category. Another possibility we advocate for discharging lemmas is through a 
peer-review process, which mimics the practice of (informally) verifying math- 
ematical proofs. Obviously, the precondition for such an approach is that the 
lemmas to be verified can be expressed in a format that is easily accessible to a 
(trained) human being. This is where the programmer-centric verification as is 
presented in this paper can fit very well. 
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